System and methods for implementing a server-based hierarchical mass storage system

ABSTRACT

Setting up and supporting the computer infrastructure for a remote satellite office is a difficult task for any information technology department. To simplify the task, an integrated server system with a hierarchical storage system is proposed. The hierarchical storage system includes the ability to store data at an off-site cloud storage service. The server system is remotely configurable and thus allows the server to be configured and populated with data from a remote location.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/393,945 (now U.S. Pat. No. 11,030,159), filed Apr. 24, 2019, which isa division of U.S. patent application Ser. No. 13/898,152 (now U.S. Pat.No. 10,552,385), filed May 20, 2013, which claims the benefit of U.S.Provisional Application No. 61/649,305, filed May 20, 2012, the contentsof the above-referenced applications are hereby expressly incorporatedherein by reference in their entirety. The present application furtherincorporates by reference the previous U.S. patent applications entitled“System and Method for Efficiently Creating Off-Site Data VolumeBack-Ups” filed on Apr. 1, 2010 having Ser. No. 12/798,321 and “SystemAnd Method For Storing Data Off Site” filed on Jan. 6, 2011 having Ser.No. 12/930,502.

TECHNICAL FIELD

The present invention relates to the field of digital mass storagesystems. In particular, but not by way of limitation, the presentdisclosure teaches several techniques for implementing hierarchical massstorage system within a server system or in cloud-based virtual machine.

BACKGROUND

Computer systems have become an indispensable tool used in modern life.Nearly every business and government entity is now dependent uponcomputer systems for digital communication, project planning, documentcreation, information storage, transaction processing, projectmanagement, inventory management, financial operations, and a largenumber of other mission critical services.

Due to the critical importance of information technology to mostorganizations, it is critical to be able to repair or replace any partof the information technology infrastructure that fails. Althoughindividual pieces of computer hardware and computer software can easilybe replaced by an entity by purchasing new computer equipment orcomputer software, the entity's accumulated store of digital informationcannot easily be replaced. Thus, digital information storage and digitalinformation protection is one of the most critical parts of any moderninformation technology infrastructure system.

Modern organizations need to be able to support a wide variety ofdifferent computer environments for their computer users. An informationtechnology department may be required to provide digital informationstorage services to a large central headquarters campus, othergeographically remote campuses, remote divisional offices, regionaldevelopment offices, small remote sales offices, and even individualsthat work alone. Ideally, all of these different sized officeenvironments could be provided with the same level of informationtechnology services and support. Furthermore, the information technologydepartment must deal with the fact that new offices open, existingoffices close, and offices may move during an organization's lifetime.Providing digital information storage services to such a wide variety ofoffice environments that may include geographically remote offices is asignificant challenge to any information technology department.Therefore, it would be desirable to develop a scalable digitalinformation storage system that can provide easily manageable andhigh-quality digital information storage services to handle any type ofcomputer environment.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, which are not necessarily drawn to scale, like numeralsdescribe substantially similar components throughout the several views.Like numerals having different letter suffixes represent differentinstances of substantially similar components. The drawings illustrategenerally, by way of example, but not by way of limitation, variousembodiments discussed in the present document.

FIG. 1 illustrates a diagrammatic representation of machine in theexample form of a computer system within which a set of instructions,for causing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

FIG. 2 illustrates a block diagram illustrating the difference between atraditional direct access storage system and a storage area network(SAN).

FIG. 3 illustrates a conceptual view of a hierarchical storage systemwherein frequently accessed data is stored near the top and lessfrequently data is stored near the bottom.

FIG. 4 illustrates a hierarchical mass storage system used within thecomputer network system of an office environment.

FIG. 5 illustrates a conceptual block diagram of one embodiment of anarchitecture used to construct a hierarchical mass storage system.

FIG. 6 conceptually illustrates a set of data storage layers in oneembodiment of a hierarchical mass storage system.

FIG. 7 illustrates a flow diagram that describes how a hierarchical massstorage system may respond to a read request received from a clientsystem.

FIG. 8 illustrates a flow diagram that describes how a hierarchical massstorage system may respond to a write request received from a clientsystem.

FIG. 9 illustrates a flow diagram that describes how a hierarchical massstorage system may divide a data chunk into data slices and removeduplicates.

FIG. 10 is a conceptual diagram that illustrates how a chunk of data maybe divided into data slices using a progressive fingerprint calculatedover a moving window.

FIG. 11A illustrates a block diagram of a data slice that has beencompressed with an extendible compression system.

FIG. 11B illustrates a block diagram of the compressed data slice ofFIG. 11A that has been encrypted with an extendible encryption system.

FIG. 12 illustrates the computer infrastructure for a small officeenvironment with just three local employees that use workstations.

FIG. 13 illustrates a small office computer environment similar to FIG.12 wherein the small server system includes an integrated hierarchicalstorage system.

FIG. 14 illustrates a detailed block diagram of one embodiment of serversystem with an integrated hierarchical storage system.

FIG. 15A illustrates a block diagram of a company with a headquartersand two satellite offices in London and Zurich that desires to open anoffice in Tokyo.

FIG. 15B illustrates the block diagram of FIG. 15A after configuring aserver in Tokyo for regional cloud-storage.

FIG. 15C illustrates the block diagram of FIG. 15B after configuring theserver in Tokyo to access a server at the headquarters.

FIG. 15D illustrates the block diagram of FIG. 15C after configuring therestoring a satellite office template volume server onto the Tokyoserver.

FIG. 15E illustrates the diagram of FIG. 15D with the Tokyo officeoperating.

FIG. 15F illustrates the diagram of FIG. 15E after backing-up theimportant data volume from the Tokyo satellite office.

FIG. 15G illustrates the diagram of FIG. 15F after closing the Tokyooffice.

FIG. 15H illustrates the block diagram of FIG. 15G after opening up anew office in Singapore with all of the data from closed the Tokyosatellite office.

FIG. 15I illustrates the block diagram of FIG. 15H wherein a libraryvolume is distributed to all of the different satellite offices.

FIG. 16 illustrates a virtual server system with an integratedhierarchical storage system that is executing at a cloud serviceprovider.

FIG. 17 illustrates two virtual server systems with an integratedhierarchical storage system that are executing at a cloud serviceprovider.

FIG. 18 illustrates a virtual hierarchical storage system with a networkstorage interface that is executing at a cloud service provider.

DETAILED DESCRIPTION

The following detailed description includes references to theaccompanying drawings, which form a part of the detailed description.The drawings show illustrations in accordance with example embodiments.These embodiments, which are also referred to herein as “examples,” aredescribed in enough detail to enable those skilled in the art topractice the invention.

The following detailed description includes references to theaccompanying drawings, which form a part of the detailed description.The drawings show illustrations in accordance with example embodiments.These embodiments, which are also referred to herein as “examples,” aredescribed in enough detail to enable those skilled in the art topractice the invention. It will be apparent to one skilled in the artthat specific details in the example embodiments are not required inorder to practice the present invention. For example, although some ofthe example embodiments are disclosed with reference to a hierarchicaldata storage system implemented within a Microsoft Windows based serversystem; the same techniques may be implemented with other. The exampleembodiments may be combined, other embodiments may be utilized, orstructural, logical and electrical changes may be made without departingfrom the scope of what is claimed. The following detailed descriptionis, therefore, not to be taken in a limiting sense, and the scope isdefined by the appended claims and their equivalents.

In this document, the terms “a” or “an” are used, as is common in patentdocuments, to include one or more than one. In this document, the term“or” is used to refer to a nonexclusive or, such that “A or B” includes“A but not B,” “B but not A,” and “A and B,” unless otherwise indicated.Furthermore, all publications, patents, and patent documents referred toin this document are incorporated by reference herein in their entirety,as though individually incorporated by reference. In the event ofinconsistent usages between this document and those documents soincorporated by reference, the usage in the incorporated reference(s)should be considered supplementary to that of this document; forirreconcilable inconsistencies, the usage in this document controls.

Computer Systems

The present disclosure concerns digital computer systems. FIG. 1illustrates a diagrammatic representation of a machine in the exampleform of a computer system 100 that may be used to implement portions ofthe present disclosure. Within computer system 100 of FIG. 1, there area set of instructions 124 that may be executed for causing the machineto perform any one or more of the methodologies discussed within thisdocument.

In a networked deployment, the machine of FIG. 1 may operate in thecapacity of a server machine or a client machine in a client-servernetwork environment, or as a peer machine in a peer-to-peer (ordistributed) network environment. The machine may be a personal computer(PC), a tablet PC, a Personal Digital Assistant (PDA), a cellulartelephone, a web appliance, a network server, a network router, anetwork switch, a network bridge, or any machine capable of executing aset of computer instructions (sequential or otherwise) that specifyactions to be taken by that machine. Furthermore, while only a singlemachine is illustrated, the term “machine” shall also be taken toinclude any collection of machines that individually or jointly executea set (or multiple sets) of instructions to perform any one or more ofthe methodologies discussed herein.

The example computer system 100 of FIG. 1 includes a processor 102(e.g., a central processing unit (CPU), a graphics processing unit (GPU)or both) and a main memory 104 and a non-volatile memory 106, whichcommunicate with each other via a bus 108. The non-volatile memory 106may comprise flash memory and may be used either as computer systemmemory, as a file storage unit, or both. The computer system 100 mayfurther include a video display adapter 110 that drives a video displaysystem 115 such as a Liquid Crystal Display (LCD) or a Cathode Ray Tube(CRT). The computer system 100 also includes an alphanumeric inputdevice 112 (e.g., a keyboard), a cursor control device 114 (e.g., amouse or trackball), a disk drive unit 116, a signal generation device118 (e.g., a speaker) and a network interface device 120. Note that notall of these parts illustrated in FIG. 1 will be present in allembodiments. For example, a computer server system may not have a videodisplay adapter 110 or video display system 115 if that server iscontrolled through the network interface device 120.

The disk drive unit 116 includes a machine-readable medium 122 on whichis stored one or more sets of computer instructions and data structures(e.g., instructions 124 also known as software') embodying or utilizedby any one or more of the methodologies or functions described herein.The instructions 124 may also reside, completely or at least partially,within the main memory 104 and/or within a cache memory 103 associatedwith the processor 102. The main memory 104 and the cache memory 103associated with the processor 102 also constitute machine-readablemedia.

The instructions 124 may further be transmitted or received over acomputer network 126 via the network interface device 120. Suchtransmissions may occur utilizing any one of a number of well-knowntransfer protocols such as the well-known File Transport Protocol (FTP).

While the machine-readable medium 122 is shown in an example embodimentto be a single medium, the term “machine-readable medium” should betaken to include a single medium or multiple media (e.g., a centralizedor distributed database, and/or associated caches and servers) thatstore the one or more sets of instructions. The term “machine-readablemedium” shall also be taken to include any medium that is capable ofstoring, encoding or carrying a set of instructions for execution by themachine and that cause the machine to perform any one or more of themethodologies described herein, or that is capable of storing, encodingor carrying data structures utilized by or associated with such a set ofinstructions. The term “machine-readable medium” shall accordingly betaken to include, but not be limited to, solid-state memories, opticalmedia, battery-backed RAM, and magnetic media.

For the purposes of this specification, the term “module” includes anidentifiable portion of code, computational or executable instructions,data, or computational object to achieve a particular function,operation, processing, or procedure. A module need not be implemented insoftware; a module may be implemented in software, hardware/circuitry,or a combination of software and hardware.

Storage Area Networks

To make enterprise data centers more efficient, the concept of a storagearea network (SAN) was introduced. A SAN allows computer applications toaccess remote computer storage devices (such as hard disk arrays,magnetic tape libraries, and optical disc storage devices) in a mannerwherein the remote storage devices appear no different than locallyattached storage devices. The use of a SAN allows multiple applicationsand servers to share storage systems. The use of shared storagesimplifies storage system administration since fewer storage systemsneed to be maintained. SANs also simplify the task of creating disasterrecovery systems for computer systems since an independent secondarystorage system located at a distant location can be used to replicatethe data being stored on a primary storage system at a primary location.

A storage area network generally operates as an integrated part of theoperating system in a computer device. Specifically, the operatingsystem provides the basic file system for handling files and the SANoperates below the file system and only provides raw logical blockstorage services to the file system. The difference between atraditional direct access storage system and a SAN is illustrated inFIG. 2.

Referring to FIG. 2, several server applications (201, 202, and 203) arerunning on a server system 210. The server applications (201, 202, and203) will generally operate on data files using the file system 211 ofserver system 210. The server applications may also bypass the filesystem 211 to read and write raw data blocks directly to storage. In acomputer system with a traditional direct attached storage system 240,the file system 211 accesses a direct attached storage controller 220 toaccess a local storage system 230. To use a storage area network (SAN)system 280, the file system 211 accesses a storage area networkcontroller 250 instead of accessing a local storage device. The storagearea network controller 250 issues storage requests on the storage areanetwork 260 to storage devices (271, 272, 273, and 274). Serverapplications that bypassed the file system 211 to directly use thedirect attached storage system 240 may similarly bypass the file system211 to directly access the SAN controller 250.

With the storage area network system 280, additional storage devices caneasily be added to the storage area network 260 as necessary. Bydecoupling server systems from their storage components, amalfunctioning server system (such as server 210) can be quicklyreplaced with a new server system that can immediately access the datafor that server which is available on the storage area network system280. Similarly, if a storage device on the storage area network 260malfunctions, that individual storage device can be replaced.

Hierarchical Mass Storage System Overview

Many different digital storage technologies have been created to storedigital data. Each different digital storage technology tends to haveits own advantages and disadvantages in terms of performance metrics,costs, power consumption, noise, reliability, etc. An ideal digitalstorage system would provide extremely high performance at an extremelylow cost. However, high performance storage technologies tend to beexpensive and consume power. Thus to store very large amounts of data,lower cost data storage technologies must be used.

Users do not use access all stored data equally. Generally, a small ofamount of “active” stored data is frequently accessed while most storeddata is rarely ever accessed. One can take advantage of this data accessusage pattern by constructing hybrid storage systems that use variousdifferent data storage technologies in a hierarchical manner. Forexample, FIG. 3 illustrates a conceptual view of one possiblehierarchical storage system embodiment wherein frequently accessed datais stored near the top and less frequently data is stored near thebottom.

At the top of the hierarchical storage system is a small amount ofbattery-backed random-access memory 320 that can very quickly handledata storage requests but is very expensive and consumes power. A user'smost frequently accessed data may be stored in the battery-backedrandom-access memory area 320 that has the lowest latency response time.The next level is a non-volatile solid-state memory layer 340 such asflash memory. The non-volatile solid-state memory layer 340 may use lesspower than the battery-backed random-access memory 320 but tends tooperate at a slower speed. Beneath the non-volatile solid-state memorylayer 340 is a magnetic hard disk storage layer 360. The magnetic harddisk storage layer 360 can be used to store massive amounts of data onan inexpensive magnetic data storage medium but the latency performanceis generally slower than the two preceding layers 320 and 340. Finally,an expandable cloud-based storage layer 380 can be used to provideever-expanding amounts of data storage. However, since an externalnetwork must be used to access the cloud-based storage, the cloud-basedstorage layer 380 will not provide quick data access service.

The present document discloses several techniques for implementingvarious different types of hierarchical mass storage systems thatprovide data storage services in a in various different types ofenvironments. The hierarchical mass storage system combines togetherseveral data storage technologies in a manner that takes advantage ofthe strengths and weaknesses of each different data storage technology.FIG. 4 illustrates one example of a hierarchical mass storage system 460for use within an office environment. The hierarchical mass storagesystem 460 combines together solid-state storage, hard disk storage, andeven a cloud-based data storage system 491 to create a synergistic datastorage system for a local storage area network 450.

The hierarchical mass storage system 460 may be used to provide massdata storage services to a typical networked computer environment.Referring to FIG. 4, a typical networked computer environment hasmultiple user workstations (421 to 427) coupled to a local area network(LAN) 430. The LAN 430 also has multiple server systems (441, 442, and443) that provide various services to the users at the workstations (421to 427). Typical server system applications include an email server forsending and receiving email messages, a database server for storingspecific structured data, and file server for storing general userfiles. The various server systems (441, 442, and 443) are coupled to thehierarchical mass storage appliance 460 on a storage area network 450.The storage network interface 461 on the hierarchical mass storageappliance 460 uses standard storage area network protocols to providedata storage services to the local server systems (441, 442, and 443).

The hierarchical mass storage system 460 uses storage technologies suchas solid-state memory (471 and 481) and hard disk storage (472 and 482)in hierarchical manner to store data locally. In one embodiment, thesolid-state memory (471 and 481) may be implemented with a nonvolatilememory technology such as flash memory. Flash memory systems aregenerally faster, use less power, output less noise, and are morereliable than hard disk drive (HDD) storage systems. The HDD storage(472 and 482) can provide very large amounts of local storage for a lowprice per bit stored. The hierarchical mass storage system 460 may alsobe coupled to a cloud-based storage system 491 through a secondinterface using an internet connection 465 in order to take advantage ofthe benefits of a remote cloud-based data storage service 491.

The use of a storage area network (SAN) interface 461 on thehierarchical mass storage system 460 allows administrators to use thehierarchical mass storage system 460 like a conventional SAN storagedevice. Multiple server systems may share the hierarchical mass storagesystem 460 using the standard storage area network 450. The use of asecond interface 465 coupled to a cloud storage provider 491 allows thehierarchical mass storage system 460 to provide additional storageresources that can be used as needed. As set forth in an earliersection, storage area networks allow administrators to decouple the datastorage function away from server systems such that only a singleunified data storage system needs to be maintained. Thus, all of theserver systems (441, 442, and 443) may be coupled to storage areanetwork 450 that is used to handle raw data storage reads and writes. Asingle hierarchical mass storage system 460 coupled to the storage areanetwork 450 may handle data storage operations for the entire storagearea network 450. (Note that additional hierarchical mass storagesystems or conventional storage devices may also be coupled to thestorage area network 450 for additional storage capacity.)

In the particular embodiment of FIG. 4, the hierarchical mass storagesystem 460 includes two different controller units: controller A 470 andcontroller B 480. These two different controller units may be used toprovide a fault-tolerant mirrored storage system wherein eithercontroller can take over if the other controller fails. Alternatively,the two controllers (470 and 480) may be used to “statically loadbalance” data volumes so that the controllers are each servicing half ofthe data storage requests when both controllers are healthy therebyincreasing performance. When either controller fails in such aconfiguration, the remaining functioning controller takes on doubleworkload, slowing down to some degree but providing continuous storageservice for all of the data volumes.

Controller unit A 470 and controller unit B 480 may each have local datastorage systems. In the embodiment of FIG. 4, each controller hassolid-state memory storage (471 and 481) and hard disk-based storage(472 and 482). The local data storage systems handle all data writerequests from the server systems (441, 442, and 443). The local datastorage systems also handles data read operations for data that iscurrently stored in the local data storage systems.

To supplement the local data storage systems, the hierarchical massstorage system 460 may also use data storage provided by a cloud-baseddata storage system 491 available on the internet 490. In hierarchicalmass storage systems that take advantage of cloud-based storage system491, the hierarchical mass storage system 460 attempts to keep allfrequently accessed data within the local data storage systems such thatthe vast majority of read operations are handled locally within thehierarchical mass storage system 460. However, when the amount of storeddata exceeds the capacity of the local data storage systems thehierarchical mass storage system 460 will begin to store less frequentlyaccessed data at the cloud-based data storage system 491. This allowsthe hierarchical mass storage system 460 to take advantage of aninfinitely large storage system that is maintained by experts that runthe cloud-based data storage system 491 while having local storageperformance for frequently accessed data (the data stored in the localdata storage systems).

As illustrated in FIG. 4, a hierarchical mass storage system 460 thatuses cloud-based data storage acts as an intermediary between an on-siteSAN 450 and an off-site cloud-based data storage provider 491. Thus, thehierarchical mass storage system 460 must reconcile the significantdifferences between the front-end interface 461 to SAN 450 and theback-end 465 interface to the cloud-based data storage system 491. Onesignificant difference is the speed differential since the SAN 450generally operates at very fast speeds (such as one gigabit per second)and the internet connection 465 may only operate at ten megabits persecond.

To compensate for the speed differential, the hierarchical mass storagesystem 460 takes advantage of the manner in which data storage systemsare generally used. Most mass data storage systems only need to handle arelatively small amount of dynamic data that is frequently accessed asset forth with reference to FIG. 3. For example, an email server needsto store new email messages every day and a file server needs to handlea limited number of files that are actively being accessed by users.However, the vast majority of the data stored on a mass storage systemis generally static and rarely accessed. For example, file servers maystore archives of old documents that are no longer being accessedregularly. Thus, since only a relatively small amount of data stored inmass data storage system is actively used, that small amount of activedata can be stored in the local data storage systems (solid statestorage 471 and 481 and local HDD 472 and 482) that can be repeatedlyaccessed at a high data rate and with low latency. The data that israrely accessed can be stored at the cloud-based data storage provider491 and retrieved only when necessary. Accessing data from thecloud-based data storage provider 491 will often result in increasedlatency; however, such latency may be acceptable in certain applicationsor use patterns. Furthermore, such latency should rarely be encounteredsince only rarely-used data will be stored at the cloud-based datastorage provider 491.

A core concept of the hierarchical mass storage system 460 is theefficient use of the local data storage available within thehierarchical mass storage system 460. As long as the hierarchical massstorage system 460 accurately identifies the data that is mostfrequently accessed and keeps that frequently-accessed data in the localdata storage (471, 481, 472 and 482) then the vast majority of storagerequests (both read operations and write operations) received on the SANinterface 461 can be serviced using only the local data storage systems(471, 481, 472 and 482). This will greatly reduce the amount of datatraffic on the interface 465 to the cloud-based data storage 491 thushiding the speed differential between the two interfaces from users ofthe hierarchical mass storage system 460.

To most efficiently use the local storage, the hierarchical mass storagesystem 460 uses both intelligent data-tiering algorithms and storagespace optimization techniques. The data-tiering algorithms are used toidentify the most frequently accessed data and keep that frequentlyaccessed data in the local storage system. The data-tiering algorithmsmay also use intelligent buffering systems like read-ahead caching toprevent cache misses. For example, by using heuristics to identify datathat is likely to be requested soon, the hierarchical mass storagesystem 460 may issue predictive requests for data currently stored atthe cloud-based data storage 491 before receiving an actual incomingrequest for such data. Various storage space optimization techniques maybe used to store as much data in the local storage space. The techniquesthat may be used include the identification and elimination ofduplicated data and data compression.

In one embodiment, the administrator of the hierarchical mass storagesystem 460 may be allowed to allocate and configure data storage in anapplication dependent manner. For example, if a particular applicationuses a certain set of data infrequently but a low latency response isneeded when that data is accessed then an administrator may be allowedto specify this limitation for that application or for that specificdata set. In this manner, the hierarchical mass storage system 460 willensure that a local copy exists or will pro-actively fetch from thecloud and move it to the local storage if previously tiered to thecloud-based storage 491. Other data sets may be explicitly marked as‘archive’ data such that the designated archive data is quickly sent offto the cloud-based storage provider 491. This prevents such archive datafrom using valuable local storage space until the data-tiering systemeventually determines that such archive data is not being frequentlyaccessed. In one embodiment, the hierarchical mass storage system mayallow an administrator to designate a data volume as a 100% localvolume. The hierarchical mass storage system 460 will ensure that such adesignated 100% local volume will be stored in some combination of localstorage.

Hierarchical Mass Storage System Architecture

Various different architectures may be used to construct thehierarchical mass storage system 460 of FIG. 4. FIG. 5 illustrates aconceptual block diagram of one particular architecture that may be usedto construct a hierarchical mass storage system 500. At the top of thehierarchical mass storage system 500 block diagram is an administrationcomponent 510 that is used for configuring, controlling, and monitoringa hierarchical mass storage system 500. An administrator may access theadministration component 510 through an interface coupled to a localarea network 505.

An administrator uses the administration component 510 to initiallyconfigure the hierarchical mass storage system 500. For the initialconfiguration, an administrator specifies which virtual storage toexpose to hosts on the storage area network (SAN) 501. This is similarto legacy systems where the administrator specifies which LUNs in astorage array to expose to hosts. The administrator also specifies theaddresses and access information for the cloud storage provider(s) 591that will be used. The administrator may specify a storage limit, butthis is generally not advisable since the hierarchical storage system500 should be allowed to grow as needed.

The administrator may also specify bandwidth constraints of thecommunication link 596 to the cloud data storage provider 591 andbandwidth constraints of the specific cloud data storage provider 591(the maximum rate at which the cloud storage provider will handle dataaccess requests). The bandwidth constraints of the communication link596 can be used to ensure that the hierarchical mass storage system 500does not attempt to send data faster than the communication link 596 canhandle the data. Furthermore, if the communication link 596 is shared byother users (such as an internet connection shared with human users,mail servers, and other internet users), the hierarchical mass storagesystem 500 can be configured to use less than the full bandwidthavailable on the communication link 596.

After initial configuration, an administrator may use the administrationcomponent 510 for several different maintenance operations. For example,the administration component 510 may be used to schedule periodicsnapshots of the data volumes in the hierarchical mass storage system500 and make back-up copies of those snapshot volumes in the cloud-basedstorage. Additional data volumes may be added to the hierarchicalstorage system 500 or existing data volumes may be removed.

The administration component 510 will collect operation statistics 511that may be used to measure the performance of the hierarchical massstorage system 500. The operation statistics 511 may be analyzed andused to alter the configuration of the hierarchical mass storage system500 to improve performance. Each lower layer in the data storage requeststack 515 may generate its own individual statistics. The administrationcomponent 510 may periodically poll the lower layers and various otherparts of the hierarchical mass storage system 500 to create acentralized collection of all the hierarchical mass storage systemstatistics.

The main component of the hierarchical mass storage system 500 is amulti-layered data storage request stack 515 that handles all datastorage requests issue to the hierarchical mass storage system 500. Datastorage requests are received at the top of the data storage requeststack 515 and the various data storage layers attempt to resolve thedata requests. When a layer cannot fully resolve a request then thatlayer passes on a request to a lower layer until the data request isultimately resolved. The details of the data storage request handlingstack 515 will be disclosed layer by layer in later sections of thisdocument.

The top layer of the data storage request stack 515 is a storage areanetwork (SAN) interface layer 520 that is coupled through front-endinterface 502 to a SAN 501. The SAN interface layer 520 receives storagerequests from local systems such as servers 507 and 508. The front-endinterface 502 of the hierarchical mass storage system 500 will generallyuse well-known SAN protocols. Examples of well-known SAN protocolsinclude the industry standard Internet Small Computer System Interface(iSCSI) protocol and the Fiber Channel Protocol (FCP). These SANprotocols allow storage clients to perform operations such as start,stop, read, write, and format on data storage units addressed by logicalunit numbers (LUNs).

The top layers (520, 531, and 532) of the data storage request handlingstack 515 handle some formalities in processing storage requests.Beneath the formality layers are a set of hierarchical data storagelayers. A first data storage layer, the linear storage layer 540, isoptimized for quickly handling data requests by locally storing data ina relatively raw format. A second data storage layer, the deduplicatedstorage layer 550, locally stores data in a more efficient manner byidentifying and eliminating duplicate data. A third data storage layer,the transient storage layer 560, is optimized for locally storing largeamounts of data in a very dense compressed form. A fourth data storagelayer uses cloud-based storage to store a limitless amount of data bystoring data off site at a cloud-based data storage provider 591. Notethat FIG. 5 only illustrates one possible hierarchical storage systemand that other hierarchical storage systems may use additional or fewerdata storage layers. To fully describe the data storage request handlingstack 515 of FIG. 5, each the layers in the storage request handlingstack will be described in further detail individually.

Front-End Interface and Initial Layers

At the top of the data storage request stack 515 is the storage areanetwork (SAN) interface 520. In one particular implementation that willbe considered in detail, the storage area network interface 520implements the well-known iSCSI protocol that is used to accept SCSIcommands carried on a TCP/IP network. However, any other data storageprotocol may be implemented at the top of the storage request handlingstack 515.

In an iSCSI embodiment, the SAN interface 520 exposes iSCSI volumes tohosts on the SAN 501. The SAN interface 520 then receives iSCSI datastorage requests from the hosts and responds to those data storagerequests. The SAN interface 520 parses iSCSI commands and determines howthe commands should be handled. Many of the administrative iSCSIrequests that are not directly related to reading and writing data canbe fully handled by the SAN interface layer 520. The SAN interface layer520 passes data storage requests down the data storage request stack 515to the next layer to handle such data storage requests.

Beneath the storage area network interface layer 520 is a volumeabstraction layer 531. The volume abstraction layer 531 handles many ofthe formalities in keeping track of the different volumes stored by thehierarchical mass storage system 500. For example, the volumeabstraction layer 531 keeps track of the data volumes that exist, thesize of each volume, access control lists (ACLs), and otheradministrative information. Thus, the volume abstraction layer 531handles some of the volume management tasks such that the lower layersof the storage request handling stack 515 can concentrate on actual datastorage.

Snapshot Layer

Beneath the volume abstraction layer 531 is a snapshot layer 532. Thesnapshot layer 532 is used for taking “snapshots” of specified datavolumes in the hierarchical mass storage system 500 upon receiving arequest for a snapshot. In the present disclosure, a snapshot is thestate of a data volume at a particular moment in time. However, it isimpractical (if not impossible) to instantly copy an entire data volume.Instead, the snapshot layer 532 creates a new volume that initially onlyconsists of a time map for the snapshot volume that specifies when thesnapshot was taken and a pointer to the parent volume. If there are nonew writes to the parent volume, then the current data of that parentvolume can be used as the data for the snapshot volume. However, when anew write operation is received that changes data in the parent volumethat is referenced by a snapshot volume, the old existing data must becopied out of the parent volume and placed in the snapshot volume beforethe write occurs in order to save the data that existed when thesnapshot volume was created. Detailed information on the snapshot layer532 can be found the U.S. patent application entitled “System and Methodfor Efficiently Creating Off-Site Data Volume Back-Ups” filed on Apr. 1,2010 having Ser. No. 12/798,321 which is hereby incorporated byreference.

High-Speed Linear Storage Layer

After performing any needed snapshot operations in the snapshot layer532, a data storage request is then passed to the linear storage layer540 that is first level of data storage in the hierarchical mass storagesystem 500. The linear storage layer 540 is high performance datastorage layer designed to handle “hot” data. Hot data is defined as datathat is frequently read and/or written.

The linear storage layer 540 will generally receive data storagerequests addressed with traditional data storage semantic terms such aslogical volumes, logical block addresses (LBA), and block transferlengths (BTL). As set forth earlier, the front-end of the hierarchicalmass storage system 500 may implement many different possible datastorage protocols that use different data storage addressing systems.However, as long as the hierarchical mass storage system 500 properlyresponds to all data storage requests received, the hierarchical massstorage system 500 is free to use any different type of addressingsystem internally.

In one embodiment, the hierarchical mass storage system 500 uses a flatlinear addressing system for each data volume wherein each logicalvolume is divided into fixed sized “chunks” that are an even multiple ofthe logical blocks (SCSI logical blocks are typically 512 bytes long)used by most disk-based storage systems. A very simple translationsystem can be used to translate data requests made in terms of logicalblock address (LBA) ranges on a disk (or any other data storageaddressing system) into the chunk-based linear addressing system usedwithin the linear storage layer 540. In one specific embodiment eachfixed-size chunk is 256 kilobytes long (which can fit 512 logical blocksthat are each 512 bytes long). However, this is merely one particulardesign choice and other sizes may be used.

The linear storage layer 540 stores data in an allocated linear storagearea 547 of local data storage. In one embodiment, solid state memorysuch as flash memory is used to store all data for the linear storagelayer 540. Flash memory can quickly handle storage requests and isnonvolatile such that the data will remain stored even if there is apower loss.

The linear storage layer 540 maintains a linear storage map 541 to keeptrack of where the all the data is stored. Specifically, for each datavolume stored in the hierarchical mass storage system 500, the linearstorage map 541 specifies where each chunk of data resides (and thus howthe data may be obtained). For data chunks that are currently storedwithin the linear storage layer 540, the linear storage map 541 mayspecify a specific physical memory address in the linear data storagearea 547. For all of the data that is not currently stored within thelinear storage layer 540, the linear storage map 541 may specify a setof data fingerprints used to uniquely identify data slices stored withinlower data storage levels of the data storage request stack 515. In oneparticular embodiment, a thirty-two-byte long SHA-256 fingerprint isused to uniquely identify data slices stored within the lower datastorage layers.

FIG. 6 conceptually illustrates how the first three various data storagelayers use the local data storage. Note that FIG. 6 is conceptual onlyand that many details are omitted for clarity. The linear storage layer640 uses a linear storage map 641 that maps each data chunk either to alocation in linear storage 647 or to a set of fingerprint identifiersthat represent the data chunk. The fingerprint identifiers are used tolocate the requested data in lower data layers of the storage requesthandling stack. In the example of FIG. 6, chunk 0 is stored in thelinear storage area 647 as indicated by a pointer. Chunk 1 is stored inlower data storage layer(s) since the linear storage map 641 specifies aset of fingerprint identifiers. Each of the fingerprint identifiersuniquely specifies a data slice of the data chunk. The set of dataslices is equal to the size of a data chunk (which is 256K in oneparticular embodiment).

The linear storage map 641 may be implemented with an ordered linkedlist that links together entries each containing a pointer to a chunk ofdata in the linear storage area 647 or a set of fingerprint identifiersfor data slices stored in lower data storage layers. For the data storedin lower data storage layers, the linked list entries will contain aseries of entries with data fingerprints where the total size of thedata slices referred to by the fingerprint identifiers equals one chunksize. To improve performance, the linked list may be supplemented byadditional data structures used to improve the search of the linkedlist. For example, a red-black tree, a hash table, or another similardata structure containing pointers to the linked list nodes may be usedto improve the speed of searching the linked list.

A description of how the linear storage layer 640 handles read requestswill be disclosed with reference to a flow chart presented in FIG. 7 andthe conceptual diagram of FIG. 6. Referring to FIG. 7, a read requestreceived from a host client is first processed by the SAN interfacelayer, the volume abstraction layer, the snapshot layer, and any otherinitial layer at stage 705. The read request is then passed to thelinear storage layer 640 to obtain the data.

The linear storage layer 640 first examines the linear storage map 641for the requested data at stages 710 and 715 to determine how to respondto the read request. If the requested data is available in the linearstorage 647 then the linear storage layer 640 simply reads the data fromthe linear storage area 647 and responds to the read request at stage720. The system may then update some statistics (such as statistics usedto determine if the data is hot, warm, or cold) at stage 780 and it isthen done handling the read request.

If the requested data was not found in the linear storage 647 at stage715, then the linear storage layer 640 requests the needed data fromlower layers of the data storage request stack at stage 730. The requestis made by requesting the fingerprints of the needed data slices. Notethat a read request may only need a few data slices of data if the readrequest only requested a small amount of data within a particular chunkof data. In this particular embodiment, the next lower layer is thededuplicated storage layer 650 in FIG. 6. This document may use the term‘dedup’ when referring to aspects the deduplicated layer.

At stage 735, the deduplicated storage layer 650 examines thededuplicated storage map 651 to determine if all the requested dataslices are in the deduplicated storage area 657. If the deduplicatedstorage layer 650 has all the needed data slices, then the deduplicatedstorage layer 650 can respond with the requested data at stage 750. Ifthe deduplicated storage layer 650 does not have all the requested dataslices, then the deduplicated storage layer 650 will request the neededdata slices from lower data storage layers at stage 740. In thisparticular embodiment, the request will be made to the next lower layerof the storage request handling stack, the transient storage layer 660.

At stage 743 the transient storage layer 660 handles the data request.Thus, the transient storage layer 660 examines the transient storage map661. If the transient storage layer 660 has the requested data, then itreturns that data. If the transient storage layer 660 does not have therequested data, then the transient storage layer 660 may request andreceive the missing data from lower data layers. The system proceeds inthis layered manner until at stage 745, the deduplicated storage layer650 receives all of the requested data from the lower layers and placesthe requested data into the deduplicated storage area 657. Thededuplicated storage layer 650 can then respond to the linear storagelayer 640 with the requested data at stage 750.

Upon receiving the requested data slices from deduplicated storage layer650, the linear storage layer 640 will assemble the requested data fromthe received data slices at stage 760. Finally, the linear storage layer640 can then respond to the read request with the requested data atstage 770. The statistics counters can then be updated at stage 780.

It can be seen that servicing the read request at stage 720 will befaster than servicing the read request when the data must be fetchedfrom the lower data storage layers. Furthermore, the lower the datalayer that must be accessed, the more time that will be required tohandle the read request.

Write requests are handled in a similar manner. All write operations tothe hierarchical mass storage system are initially written into thelinear storage 647 associated with the linear storage layer 640. Thehandling of a write request will be disclosed with reference to the flowchart of FIG. 8 and the conceptual diagram of FIG. 6. The example ofFIG. 8 describes a write to a single data chunk. However, the same stepsmay be performed multiple times to handle writes to multiple datachunks.

Referring to FIG. 8, a write request received from a host client isfirst processed by the initial formality layers such as the SANinterface layer, the volume abstraction layer, and the snapshot layersat stage 805. The write request is then passed to the linear storagelayer 640 where the linear storage layer 640 first examines the linearstorage map 641 at stages 810 and 815 to determine how to handle to thewrite request. If the write is directed at a data chunk that is alreadyavailable in the linear storage area 647 then the write request ishandled by proceeding to stage 850 and writing the new data into theappropriate data chunk within the linear storage area 647 at stage 850.The system may then also update some statistics at stage 860. At thispoint, the write request has been fully handled using only the linearstorage layer 640.

If the data chunk that the write request is directed at was not found inthe linear storage area 647 at stage 815, then the linear storage layer640 will generally first pull the data for the target data chunk intothe linear storage layer 640 to over write the existing data. The reasonthat data is pulled up into the linear storage layer 640 before it isoverwritten is so that if a failure occurs during a write operation, thefailure will at least leave the old data which has been partiallyover-written by new data. This is the way that a traditional disk-basedstorage system operates such that application programs are alreadyprepared to handle corrupted data due to such a failure occurring duringa write operation.

To pull the target data up into the linear storage area 647, the linearstorage layer 640 may first need to allocate a new chunk of memory inthe linear storage area 647 at stage 820. (Generally, the system willalways keep a few memory chunks available for handling new incomingwrite options.) Allocating a new memory chunk may be performed byspilling data from an existing chunk in the linear storage area 647 downto a lower data storage layer. Spilling a data chunk down to a lowerdata storage layer will be described in a later section of thisdocument.

With a memory chunk available in the linear data storage area 647, thelinear storage layer 640 then requests all the data slices for that datachunk from the lower data storage layers of the data storage requeststack at stage 830. The request for the data slices is made by providingthe fingerprint identifiers of the needed data slices. Note that all ofthe data slices for the data chunk being over-written are required sincethe entire data chunk will now be represented in the linear storage area647 as a single data chunk. If the deduplicated storage layer 650 doesnot have all the needed data slices for the chunk in the deduplicatedstorage 657, then the deduplicated storage layer 650 will request themissing data slices from the next lower data storage layer of the datastorage request stack (the transient layer 660 in this embodiment).

After receiving the requested data slices from the lower data storagelayers, the linear storage layer 640 then assembles the data slices in abuffer at stage 840. The fully assembled data chunk is then copied intothe free memory chunk in linear storage area 647 such that the linearstorage layer 640 is now fully responsible for that particular datachunk. Thus, the linear storage layer 640 updates the linear storage map641 to reflect that the linear storage layer 640 now has that particularchunk of memory represented within the linear storage area 647.

It should be noted that the fetched data slices will generally beallowed to also remain down in the deduplicated storage area 657. Aprimary reason that these data slices will continue to be in thededuplicated storage area 657 is that other areas of the data volume (orother data volumes) may refer to the same fetched data slices. If a dataslice is not referenced by any data chunk, then a garbage collectionmechanism may eventually discard that unreferenced data slice.

Unreferenced data slices may be allowed to remain in the deduplicatedstorage area 657 for some time. There is actually a benefit in keepingunused data slices in the deduplicated storage area 657 for a period oftime. Specifically, a data chunk that was pulled up from thededuplicated storage layer 650 (or lower layers) up into the linearstorage layer 640 may soon be spilled back down to the deduplicatedstorage layer 650. When this occurs, the pre-existing data slice in thededuplicated storage area 657 may be used again if the data slice stillrepresents a portion of the data chunk.

Referring back to FIG. 8, after the data chunk has been fully moved backup into the linear storage area 647 and assembled at stage 840 thelinear storage layer 640 may then over-write the data chunk at stage850. In the unlikely event of a failure during the write, the data chunkwill contain a mix of new data overwritten onto old data. As set forthabove, this is a situation that existing application programs arealready prepared to handle. Finally, at stage 860, the system may updatesome statistics. For example, a counter associated with the data chunkmay be incremented to indicate that the data chunk has recently beenaccessed. This counter value may be used by a data-tiering algorithm todetermine if the data chunk should be kept in the linear storage layer.

In most circumstances, the hierarchical mass storage system will onlyspill data down to lower data storage layers of the storage requeststack when a particular storage layer needs evict old data to make roomfor new data. For example, the linear storage layer 640 may evict a datachunk to make room for new data in the linear storage area 647. Theeviction policy may use eviction policies similar to common cachereplacement strategies. For example, the system may use the well-knownleast-recently used (LRU), least-recently allocated (LRA), orleast-frequently used (LFU) cache replacement policies to determine whena data chunk may be evicted from the linear storage layer 640. A latersection of this document will describe additional details on dataeviction.

Memory Efficient Deduplicated Layer

Referring back to FIG. 5, when the linear storage layer 540 determinesthat a particular data chunk is not being frequently accessed then thelinear storage layer 540 spills that data chunk down to lower datastorage layers for more efficient storage of the data chunk. In oneembodiment, the linear storage layer 540 sends the data chunk to thededuplicated storage layer 550 for storage in the deduplicated storagearea 557. The deduplicated storage layer 550 acts as a repository for“warm” data that is not as frequently accessed as the “hot” data in thelinear storage layer 540 but still accessed regularly and typically readmore often than written. As the name implies, the deduplicated storagelayer 550 attempts to remove duplicated data from the stored data suchthat the deduplicated storage layer 550 stores data more efficientlythan the linear storage layer 540.

In the deduplicated storage layer 550 (and all the lower data storagelayers in this embodiment), the data is stored as data slices. Each dataslice is uniquely identified with a data fingerprint (such as a SHA-256fingerprint). The deduplicated storage layer 550 may use a deduplicatedstorage map 651 to keep track of where each data slice is stored withinthe deduplicated storage area 557 of the local data storage system. FIG.6 illustrates a conceptual diagram of the deduplicated storage map 651and the deduplicated storage area 657.

As illustrated in FIG. 6, the deduplicated storage map 651 may beimplemented as a table that lists, for each data slice, the datafingerprint and the storage location of each data slice within thededuplicated storage area 657. In practice, the deduplicated storage map651 may be implemented as a hash table (or similar data structure) tooptimize search performance. If a requested data slice is not storedwithin the deduplicated storage area 657 then that data slice may bepresumed to be stored in lower data storage layers.

When the linear storage area 647 is filled, the linear storage layer 640must select one or more linear data chunks to spill down. In oneembodiment, the linear storage layer 640 uses a “least recentlyallocated” (LRA) policy to determine when a particular data chunk shouldbe spilled down to a lower data storage layer. The spilling down of datachunks may be performed by a background spill process that attempts tokeep the linear storage area 647 approximately 85% full in oneparticular embodiment. This allows a large amount of data to be storedbut keeps the linear storage layer 640 prepared to accept a new burst ofdata writes.

FIG. 9 illustrates a flow diagram describing how a data slice may bespilled down from the linear storage layer 640 to the deduplicatedstorage layer 650. At stage 920, the linear storage layer 640 dividesthe data chunk into a set of individual data slices at stage 920. Manydifferent techniques may be used to slice a data chunk (as used in thelinear storage layer) into a set of data slices (as used in the lowerdata storage layers). The goal is to slice each data chunk up intoindividual data slices in a manner that will result in a highprobability of identifying duplicate data slices. In one particularembodiment, each data chunk is sliced up using Rabin fingerprints. ARabin fingerprint is a progressive polynomial that is calculated over adefined window. It is progressive since successive Rabin fingerprintsmay be calculated by dropping of a byte from one end of the definedwindow and adding another byte to the other end of the defined window.This allows a Rabin fingerprint to sweep through a chunk of datadividing it into data chunks.

FIG. 10 conceptually illustrates how a Rabin fingerprint calculatorwindow 1050 may sweep through data chunk 1010 progressively calculatingRabin fingerprints. The Rabin fingerprint system may be used to sweepthrough the data chunk 1010 and periodically drop anchors to define dataslices. An anchor may be dropped when the Rabin fingerprint equals somearbitrary value. In one particular embodiment, the system creates dataslices that start at a first anchor defined by the beginning of the datachunk or the previous anchor, are at least 8K bytes long, and end whenthe specified arbitrary Rabin fingerprint value is generated or a 64Klimit is reached (whichever occurs first). This implementation willcreate data slices that are all between 8K and 64K in length. If thearbitrary value is selected as a value with 16 zeroes in the leastsignificant bits of the binary Rabin figure print, the data slices willaverage to be around 16K in size.

Referring back to FIG. 9, at stage 930 the system then may need toallocate space in the deduplicated storage area 657 if no space isavailable. This may be done by selecting a least recently allocatedchunk of space in the deduplicated storage area 657 and spilling thedata slices in that area down into a lower data layer. Note that, likethe linear storage layer 640, the deduplicated storage layer 650 mayalso have a background process running that always attempts to keep thededuplicated storage area 657 approximately 85% filled such that thededuplicated storage layer 650 stores a large amount of data but canstill always accept new data.

After dividing the data chunk into data slices and ensuring that spaceexists in the deduplicated storage layer 650, the linear storage layer640 then begins to spill down individual data slices from the datachunk. At stage 940, the linear storage layer 640 first calculates adata fingerprint for a data slice. This fingerprint is a statisticallyunique identifier fingerprint such as a SHA-256 fingerprint. The linearstorage layer 640 then provides the data slice and the fingerprint forthe data slice to the deduplicated storage layer 650 at stage 950. (Thedata may be provided by simply passing a pointer to the data slice.)

Next, at stage 970, the deduplicated storage layer 650 examines thefingerprint identifier that it receives and searches the deduplicatedstorage map 651 to see if there is already an existing identical dataslice already stored in the deduplicated storage area 657. Withsufficiently strong fingerprint identifiers that have an extremely lowprobability of aliasing, simply comparing the fingerprint identifiersmay be enough to identify duplicate data. In an alternative system, thededuplication may be performed in two stages. A first stage can useprobabilistic methods to locate potential duplication candidates. Afteridentifying candidates for deduplication, exhaustive algorithms verifythe duplicated data and possibly adjust the data slice boundaries toobtain more duplicated data slices.

If the deduplicated storage layer 650 identifies redundant data, thededuplicated storage layer 650 may discard the data at stage 980. Inembodiments wherein the system maintains a reference counter to keeptrack of how many different data chunks refer to a particular dataslice, the system may increment that reference counter. When a receiveddata slice is not yet represented in the deduplicated storage layer 650(the same fingerprint was not found in the deduplicated storage map 651at stage 975), then the deduplicated storage layer 650 adds that dataslice to the deduplicated storage map 651 at stage 990. Specifically,the deduplicated storage layer 650 stores the actual data slice in thededuplicated storage area 657 and creates a new entry in thededuplicated storage map 651 (which may be a hash table) that includesthe data fingerprint identifier and a pointer that points to the newlyadded data slice.

At stage 995, the linear storage layer 640 determines if this was thelast data slice of the data chunk to spill down. If it is not, thelinear storage layer 640 returns back to stage 940 to spill down anotherdata slice. If this was the final data slice from the data chunk, thenthe linear storage layer 640 may now update the linear storage map 641by removing the pointer to the data chunk in the linear storage area 647and adding data fingerprint identifier entries for all of the dataslices that make up the data chunk into the linear storage map 641.Thus, when a subsequent memory request is received that refers to thatparticular memory chunk, the system will need to access the data slicesnow stored in the deduplicated storage area 657 (or in lower datastorage layers) by using the fingerprint identifiers.

By removing duplicated data at stages 975 and 980, the deduplicatedstorage layer 650 greatly increases the storage efficiency. This allowsmany more logical volumes of data to be stored in the local storagelayers beneath the linear storage layer 540 that only stores data in araw unprocessed form. However, this increased data storage efficiencycomes at a cost. The linear storage layer 540 must slice up each datachunk and calculate fingerprint identifiers for each data slice. Thededuplicated storage layer 550 must handle the identification andelimination of duplicated data slices. Furthermore, spilling data intothe deduplicated storage layer 550 involves significant metadata updatesto maintain the deduplicated data storage map 651. However, sinceprocessing power is now very inexpensive and the bandwidth of the localstorage layer is far greater than the bandwidth to the cloud datastorage, this is a worthy trade-off

Another cost for the improved memory efficiency is that when a readrequest is received for a data chunk in the deduplicated storage layer650 then that read request must be satisfied with disassembled data fromthe deduplicated storage area 657. Thus, the linear storage layer 640must fetch each needed data slice from the deduplicated storage layer650 (or lower data storage layers) and then reassemble the data slicesto obtain the requested data chunk. This means that the latency time forread requests that are serviced by the deduplicated storage layer 650will be higher than the latency time for read requests that are servicedby the linear storage layer 640. However, this latency difference isrelatively small and worth the trade-off since data deduplication allowsmuch more data to be stored within the high-speed deduplicated storagearea 657. Storing more data in the high-speed deduplicated storage area657 will mean fewer accesses to the lower (slower) data storage layersthat store data on hard disk or with the off-site cloud data storageprovider which will have a much greater latency time.

Referring back to FIG. 5, the deduplicated storage layer 550 acts as arelatively fast local tier of data storage. The “warm” data in thededuplicated storage layer 550 is not accessed as frequently as the datain the linear storage layer 540 but data in the deduplicated storagelayer 550 is still accessed on a fairly regular basis. Although, thededuplicated storage layer 550 stores data more efficiently, thededuplicated storage layer 550 will eventually run out of storage space.When the deduplicated storage layer 550 runs out of storage space, thededuplicated storage layer 550 must begin to evict existing data slicesto make room for new data slices. The deduplicated storage layer 550will spill the evicted data slices further down the storage requesthandling stack 515.

Note that data eviction policies used by the deduplicated storage layer550 may be the same, similar, or different than the data evictionpolicies used by the linear storage layer 540. Referring to FIG. 6, someimplementations of the deduplicated storage layer 650 may maintain a‘reference counter’ value in the deduplicated data storage map 651 thatmaintains a count of the number of times each data slice is referencedby a data chunk. In embodiments that implement such a reference counter,the reference counter may be used by the data eviction algorithm suchthat data slices that are referenced many times are less likely to beevicted from the deduplicated storage layer 650.

In addition to spilling data down in order to make more storage spaceavailable the deduplicated storage area 557, the deduplicated storagelayer 550 may proactively spill data slices down to the lower datastorage layers before it is necessary to do so. In particular, it can bevery advantageous to proactively spill data out to the cloud storageprovider 591 before being requested to do so. This allows the bandwidthof the communication link to the cloud data storage provider 591 to beused more efficiently since data slices can be sent when there is idlebandwidth. However, the data slices may also remain locally within thehierarchical mass storage system 500 such that read requests for thosedata slices may be serviced quickly.

Transient Storage Layer

Referring to FIG. 5, read requests for data slices that cannot be fullyserviced by the previous two data storage layers are passed thetransient storage layer 560. The transient storage layer 560 may be usedto store “lukewarm” data that is accessed relatively infrequently. Thetransient storage layer 560 may store data onto hard disk drives thatcan offer very large amounts of data storage for a low cost. However,storing data on a hard disk drive instead of within solid state memory(SSM) means that there will be a slightly longer latency time whenresponding to read requests.

When deduplicated storage layer 550 is filled, it will spill data slicesdown to the transient storage layer 560. Referring to the embodiment ofFIG. 6, the transient storage layer 660 may maintain its own transientstorage map 661 that identifies the locations of data slices storedwithin the transient storage area 667.

Referring back to the embodiment of FIG. 5, all data slices spilled downto the transient layer 560 pass through a compression layer 559 thatcompresses the data slices to store the data more compactly within thetransient storage layer 560. The compression layer 559 may allowmultiple different compression systems to be used. To enable this, thecompression layer 559 may prepend compression information 1115 onto thecompressed data slice 1110 as illustrated in FIG. 11A. The compressioninformation 1115 may include a code to that specifies the particularcompression algorithm and version used to compress the compressed dataslice 1110. This allows the compression layer 559 to select the properdecompression system when multiple different compression systems arebeing used. Such an extensible system may be able to select the optimumcompression system for a particular data slice. Furthermore, this allowsnew compression algorithms to be added to the system over time.

The compression of the data slices accomplishes two goals. First, thecompression reduces the amount of data that needs to be stored in thetransient storage 567 such that the amount of data that can be storedlocally within the hierarchical mass storage system 500 is increased.And second, the compression reduces the bandwidth usage on the internetconnection 596 if the data slices are eventually sent to the datastorage provider 591. Reducing the bandwidth usage is very importantsince this reduces the large disparity between the high-speed bandwidthat the front-end storage area network connection 502 and this back-endinternet connection 596 to the cloud data storage provider 591.

Cloud Storage Layer

Referring to FIG. 5, beneath the transient storage layer 560 is a cloudstorage layer 580 that may be used to store data at an off-site cloudstorage provider 591. Data stored off-site will generally introduce somelatency when that data is read back. The cloud storage layer 580 may beused in various different manners depending on how the hierarchical massstorage system 500 is configured. For example, a hierarchical massstorage system 500 may be instructed to use the cloud storage layer 580for back-up operations only, for normal data storage only whenabsolutely necessary, or as just another layer of the hierarchical datamass storage system 500.

In a “back-up only” configuration, the hierarchical mass storage system500 is designed to only use the local storage layers (linear,deduplicated, and transient) as primary data storage. In such aconfiguration, the cloud storage layer 580 is only activated when anadministrator specifically requests that an off-site back-up volume becreated. If the hierarchical mass storage system 500 device runs low onstorage space in the local storage layers then an administrator of thesystem will be warned such that the administrator can add more localstorage capacity, delete data to create more local space, or change theconfiguration to begin using the cloud storage layer 580 for normal datastorage. Using the “back-up only” configuration ensures that all of thedata will always be available locally such that if the data link 596 tothe cloud storage provider 591 were to malfunction, all of the datavolumes would still be available locally. Furthermore, using the“back-up only” configuration will ensure that there is never a longlatency time for data requests because all of the data will be availablelocally within the hierarchical mass storage system 500.

In an “only when necessary” configuration, the hierarchical mass storagesystem 500 will always attempt to keep all of the data locally. However,if there is insufficient storage space left in the local storage layers(linear, deduplicated, and transient) then the hierarchical mass storagesystem 500 will begin to store data at the off-site cloud storageprovider 591. The administrator will be notified that off-site data isoccurring such that the administrator can take various actions inresponse. As set forth above, the administrator may add more localstorage capacity, delete data to create more local storage space, orbegin using the cloud storage layer 580 for normal data storage.

Finally, in a normal “cloud storage” configuration, the hierarchicalmass storage system 500 uses the cloud storage layer 580 as just anothersuccessive data storage tier. In one such embodiment, there are threedifferent layers of local storage (linear, deduplicated, and transient)and a fourth infinitely-extensible cloud storage layer. When in normalcloud storage mode, the hierarchical mass storage system 500 would neverrun out of storage space due to the use of extensible cloud storage. Innormal cloud storage mode, the cloud storage layer 580 stores “cold”data, data that is rarely accessed, at the cloud storage data provider591. Since it takes time to retrieve data from the off-site data storageprovider 591, there will generally be a larger latency period for anydata storage request that requires access to the off-site cloud datastorage provider 591. Ideally such latency should only rarely occur whenaccessing old data archives since the vast majority of the frequentlyused data should be represented in the local storage layers of thehierarchical mass storage system 500.

When a higher data storage layer spills a data slice down toward thecloud storage layer 580, a barrier layer 570 first stores a copy of thedata slice in a barrier storage area 547. The barrier storage area 547is used to temporarily store a copy of data that the cloud storage layer580 will transmit to the data storage provider 591. FIG. 5 illustratesthe barrier storage area 547 in SSM, but the barrier storage may be inSSM or on a hard disk drive. The barrier layer 570 stores data slices inthe barrier storage 577 for a ‘settlement period’ that allows the datastorage provider 591 to fully complete its own data storage tasks. Ifdata sent to the data storage provider 591 were requested too soon, thedata storage provider 591 may fail at providing the data since the datastorage provider 591 may not be ready to respond to data queries yet.Thus, when the transient storage layer 560 spills down a read requestfor, the barrier layer 570 first checks the barrier storage area 547 tosee if the requested data is available there. If the requested data islocated in the barrier storage area 547 then the barrier layer 570 willrespond to the data request using that data slice located in the barrierstorage area 547. If the requested data slice is not located in thebarrier storage area 547 then the barrier layer 570 will pass the readrequest down to the cloud storage layer 580 so the cloud storage layer580 can request the data slice from the cloud data storage provider 591.

In addition to allowing transmitted data slices to settle at the datastorage provider 591, the barrier layer 570 serves additional purposes.One important purpose is to handle storage request serialization. Manycloud data storage providers will perform data storage requests receivedin close time proximity out of the original order that the data storagerequests were received in. Thus, if a purge request is transmitted andthen followed a write request to the same data location, the cloud datastorage provider 591 might reverse the order of these requests such thatthe system writes the data and then purges the data thereby destroyingdata! To prevent this potential disastrous occurrence, the barrier layer570 will place a long waiting period between data storage requests thatrefer to the same data slice.

Before the cloud storage layer 580 transmits data to the data storageprovider 591, the cloud storage layer 580 first prepares the data slicesto be sent. Specifically, the data slices may first be encrypted byencryption layer 583. By encrypting the data, the user of thehierarchical mass storage system 500 does not need to fear for theirdata security. The encryption prevents any person tapping the interneconnection 596 or examining the data stored at the storage provider 591from being able to understand the real meaning of the data.

Many different data encryption systems may be used within the encryptionlayer 583. In one particular embodiment, the AES-256 encryption systemwas implemented within the encryption layer 583. As with the compressionstage, the encryption layer 583 may allow multiple different encryptionsystems to be used by prepending encryption information 1125 to theencrypted data slice 1120 as illustrated in FIG. 11B. The encryptioninformation 1125 allows the encryption layer 583 to select the properdecryption system and version when multiple different data encryptionsystems may be used. The prepended encryption information 1125 may alsospecify the size of the enclosed data slice since some encryptionsystems only operate on fixed size data and thus require padding bytes.Note that the use of pre-pending compression 1115 and encryptioninformation 1125 allows new compression and encryption systems to beadded to the hierarchical mass storage system 500 at any time.

The use of prepended encryption information 1125 may also be used tohelp with encryption key management. Encryption keys may be changed on aregular basis to improve the data security. A code may be placed intothe prepended encryption information 1125 to help select the proper keyfor data decryption. In one embodiment, the system allows anadministrator to use a passphrase to generate an encryption key.Multiple levels of authority may be used to protect keys from be lost.In addition, a built-in system may allow a customer to contact themanufacturer of the hierarchical mass storage system 500 system if thepassphrase for an encryption key has been lost.

After storing a copy in the barrier storage 577 and being encrypted bythe encryption layer 583, the compressed and encrypted data slice isprovided to the cloud storage layer 580 that is responsible fortransmitting data slice to the data storage provider 591. The cloudstorage layer 580 first creates a new data object within the cloud datastorage provider 591 to store the data slice. In one embodiment, thecloud storage layer 580 uses the same the fingerprint identifier fromthe previous storage layers as the name for the data object. The cloudstorage layer 580 then writes (transmits) the data to the newly createddata object. The cloud storage layer 580 then allows for the settlementperiod wherein it waits a specified amount of time before the data canbe read back from the data storage provider 591. This settlement periodis a time value that may be configured based upon the particular datastorage provider 591 that is being used. Once the settlement periodexpires, the cloud storage layer 580 informs the barrier layer 570 thatthe barrier layer 570 may delete the copy of the data slice that wasplaced in the barrier storage 577. Thus, subsequent read operations forthat data slice must be serviced by requesting the data slice back fromthe cloud data storage provider 591.

To ensure that the data was properly stored with the data storageprovider 591, the cloud storage layer 580 may calculate a checksum valueof data using the same type of checksum used by the data storageprovider 591. After receiving data for storage, the data storageprovider 591 may transmit a checksum value back in an acknowledgementmessage. If the two checksum values do not match, the cloud storagelayer 580 may retransmit the data slice. When such checksums are used,the copy of the data in the barrier storage 577 should not be removeduntil matching checksums have been achieved and the settlement periodhas expired.

Unlike the higher storage layers, the cloud storage layer 580 does notneed to maintain a map of the data slices. The data storage provider 591is responsible for maintaining a system that links data slicefingerprint identifiers to the data slice objects such that the cloudstorage layer 580 can request and obtain data slices back from the datastorage provider 591.

Data read requests passed down by the transient storage layer 560 arehandled in basically the same manner as write requests but in reverseorder. As set forth above, the barrier layer 570 will first attempt toserve a data request using data stored in the barrier storage 577. Ifthe data request cannot be served from data in the barrier storage 577,the cloud storage layer 580 will send a read request to the cloud datastorage provider 591 using the data slice fingerprint identifier as thename of the requested data object. After receiving a response from thecloud data storage provider 591, the cloud storage layer 580 can performdata integrity check on the received data slice by calculating achecksum the received data. If the calculated checksum does not matchthe checksum received from the deduplicated storage layer 550 then thecloud data storage provider 591 may have corrupted the data. Retries maybe attempted to obtain the proper data from the cloud data storageprovider 591. If the proper data cannot be retrieved, a ‘media error’message may be propagated back up the data storage stack 515.

When verified data has been received, that verified data is thenprovided to the encryption layer 583 for decryption. The decrypted datais then passed to the transient storage layer 560 where the data slicemay be stored in transient storage 567. However, to handle the data readrequest, the data slice is decompressed by the compression layer 559 andthe requested data slice is passed further up the request handling stack515. The deduplicated storage layer 550 will receive the data slice thatwas fetched from the cloud and may place that data back into itsduplicated storage area 557. The deduplicated storage layer 550 passesthe requested data up to the linear storage layer 540 and finally thelinear storage layer completes the read request by assembling therequested data as set forth in stage 760 of FIG. 7.

Note that as a data slice is passed back up the data request handlingstack 515, the data slice may be stored within several different storagelayers of the data request handling stack 515 and will continue toremain at the cloud data storage provider 591. If the deduplicatedstorage layer 550 again evicts a data slice that was also stored in thetransient storage layer 560 (and that data slice has not changed) thenthat data slice does not need to be stored in the transient storagelayer 560 again since it already exists there. Thus, the deduplicatedstorage layer 550 may just delete its copy of the data slice.

The data request handling stack 515 and its various data storage layersmay be implemented in various different manners depending on the needsof a specific application. Note that the various different techniquesmay be used independently or in a combined hierarchical mass storagesystem 500.

Scaling the Hierarchical Data Storage System

The hierarchical mass storage system 500 of FIG. 5 may be implemented asmass storage appliance 460 for an office environment as illustrated FIG.4 wherein the mass storage appliance 460 provides data storage servicesto several server systems (441, 442, and 443). The server systems (441,442, and 443) provide various services to a collection of userworkstations (421 to 427). However, the office environment depictedwithin FIG. 4 will generally require a local information technologydepartment to configure and maintain the local area network 430, thevarious server systems (441, 442, and 443), the storage area network450, the hierarchical mass storage system 460, and the account with thecloud storage provider 491.

For a small office or a remote branch office, it is generally notfeasible to employ a dedicated information technology employee. Forexample, FIG. 12 illustrates the computer infrastructure for a smalloffice environment with just three local employees that use workstations1221, 1222, and 1223. Besides the three workstations (1221, 1222, and1223), the small office of FIG. 12 consists of a local area network1230, a small local server 1250, and an internet gateway device 1271that provide internet service. The small local server 1250 runs a fewserver applications such as server application A 1256 and serverapplication B 1257 that provide some local services to the office suchas file sharing, print sharing, email, etc.

Although the computer infrastructure of FIG. 12 is much simpler than themore sophisticated infrastructure of FIG. 4, some information technologymaintenance will still be required. For example, the direct attachedstorage (DAS) 1251 of server system 1250 needs to be maintained andperiodic back-ups of the server's direct attached storage (DAS) 1251must be performed using back-up system 1259. Thus, in order to maintaineven the very limited infrastructure of FIG. 12, an informationtechnology (IT) person from a larger office must periodically visit thisoffice, an outside IT person must be hired on a contract basis, or oneof the employees of the office must spend part of their time working onIT issues for the small office.

Instead of requiring an information technology person to visit the smalloffice of FIG. 12, it would be desirable if all the data storageservices for the office could be handled remotely. To provide such asolution, the present disclosure proposes integrating a remotelycontrollable hierarchical storage system into the server system 1250.Specifically, FIG. 13 illustrates a small office computer environmentvery similar to FIG. 12 wherein the small server system 1350 includes anintegrated hierarchical storage system 1355. The integrated hierarchicalstorage system 1355 provides data storage services to the applicationsthat run on the server system 1350 (Application A 1356 and Application B1357).

The small office environment of FIG. 13 with a server system 1350 thatincludes an integrated hierarchical storage system 1355 provides severaladvantages over the traditional small office environment of FIG. 12. Forexample, the integrated hierarchical storage system 1355 uses acloud-based data storage service 1391 to provide ever-expanding storagecapacity to the server system 1350. Furthermore, the integratedhierarchical storage system 1355 uses data deduplication and compressiontechniques to use the local storage capacity within the direct attachedstorage 1351 very efficiently. But one of the most important aspects ofthe integrated hierarchical storage system 1355 is the remoteadministration capabilities.

As set forth with reference to FIG. 5, a hierarchical storage system 500includes an administration component 510. The administration component510 allows the hierarchical storage system 500 to be configured andmaintained remotely through a network interface. Referring back to FIG.13, this means that an administrator 1311 at the IT department of acompany headquarters 1310 (or at contract agency) can remotely access,configure, and maintain all of the data storage functions of the serversystem 1350. Data storage related maintenance tasks generally require aperson to be physically present since the administrator must often dealwith the physical storage hardware. For example, an administrator mayneed to physically replace existing hard disk drives with larger harddisk drives when an office has outgrown the current data storagecapacity. However, since the hierarchical storage system 1355virtualizes disk volumes and uses ever-expandable cloud-based storage,the hierarchical storage system 1355 allows most data storagemaintenance tasks to be handled remotely.

For example, with a traditional small office server 1250 as illustratedin FIG. 12, a local administrator must usually be present to handle thephysical back-up media when backing-up the directed attached storage1251 with back-up system 1259. But in the server system 1350 of FIG. 13with an integrated hierarchical storage system 1355, a remoteadministrator 1311 may instruct the hierarchical storage system 1355 tocreate back-ups of data volumes in the cloud-based data storage 1391.Similarly, when a new data volume is needed to store more data, theremote administrator 1311 may instruct the hierarchical storage system1355 to create a new data volume. The creation of a new data volume willnot require the physical addition of a new disk since the hierarchicalstorage system 1355 will instead evict old inactive data from the localdirected attached storage 1251 as needed to create room for the new datavolume. Thus, as long as the local storage systems are able to handlethe data that is actively used on server system 1350, no new localstorage will be required. Instead, the cloud-based data storage 1391acts as an ever-expanding storage system.

Integrated Hierarchical Data Storage System Details

The integrated hierarchical storage system 1355 may be implemented in avariety of different ways. FIG. 14 illustrates a detailed block diagramof one embodiment of server system 1400 with an integrated hierarchicalstorage system 1404. The hierarchical storage system 1404 may beimplemented within Microsoft Windows, Linux, and other operatingsystems.

In the server system 1400, the software environment is divided into userspace and operating system (or kernel) space. The operating system,various libraries, and device drivers execute in the operating systemspace. Programs running in the operating system space are granted moreprivileges and are able to access hardware features directly. Forsecurity reasons, application programs execute in a user space that isgranted fewer privileges and is not allowed to access hardware featuresdirectly. For example, application A 1456 and application B 1457 executein the user space. This arrangement allows computer systems to operatein a more robust manner since application programs, whetherintentionally malicious or merely poorly written, are prevented fromperforming operations that would cause the server system to crash.

To access storage resources (which requires access to some data storagehardware), application programs must issue requests to the operatingsystem 1479. For example, application A 1456 and application B 1457 mayissue storage requests through operating system 1479 that are providedto a virtual storage driver 1480 that handles data storage requests. Ina typical computer system, a normal storage driver would fulfill thestorage requests by storing data onto a data storage device such asdirect attached storage 1475. However, in the embodiment of FIG. 14, thevirtual storage driver 1480 instead appears to make virtual disk volumes1451, 1452, and 1453 available but handles the storage requests forthese virtual disk volumes by passing the requests to the hierarchicalstorage system 1404. In Windows Server environment, the virtual storagedriver 1480 may be implemented as a Storport driver. In a Linuxenvironment, the virtual storage driver 1480 may be implemented as avirtual SCSI device driver.

Note that by implementing the system at the virtual storage devicedriver, the disclosed system handles all types of storage requests.Specifically, referring back to FIG. 2, an application program may makea storage request through the file system 211 of an operating system ormay make a direct storage request to a storage control system to store araw block of data. By implementing a virtual storage driver 1480 withinthe operating system space, the disclosed system can handle advancedstorage requests from applications such as databases that use raw blockstorage requests instead of simple file requests through the filesystem.

In the particular embodiment disclosed in FIG. 14, the data storagehandling stack of the hierarchical storage system 1404 is implementedwithin user space. This may be done since there are more programmingsupport tools for developing in user space and user space applicationsdo not require approval from the entity that creates the operatingsystem. However, in other embodiments, the data storage handling stackmay be implemented in the operating system space. The virtual storagedriver 1480 passes all storage requests to a driver interface 1420 atthe top of the data storage handling stack. The data storage request isthen processed by the various different layers of the data storagehandling stack until the request is fully resolved. To handle local datastorage, the various data storage layers (linear storage 1440,deduplicated storage 1450, transient storage 1460, etc.) access a realstorage driver 1474 that handles storage requests for a real directattached storage device 1475 in the server system.

Various different embodiments may use various different types of datastorage for different levels. For example, to implement ahigh-performance system, the linear storage layer 1440 may usesolid-state storage to reduce latency and have high throughput. However,in a small office environment as illustrated in FIG. 13, low latencyperformance may not be of paramount performance such that all of thelocal data storage levels may simply use a local hard disk drive system.Although such a disk-based integrated hierarchical storage systemembodiment will not provide very low latency or high throughput, theintegrated hierarchical storage system 1404 will still benefit from theincreased storage efficiency provided by performing data duplication inthe deduplication storage layer 1450 and data compression in thetransient storage layer 1460. More importantly, the server-basedhierarchical storage system 1404 will benefit from a wealth of storagemanagement features such as remote volume creation, cloud-basedback-ups, ever-expanding storage size without hardware upgrades, remotevolume duplication, centralized storage management across multiplesites, etc. The importance of these features will be described ingreater detail in the next section.

The cloud storage layer 1481 of the data storage handling stackinteracts with a cloud data storage provider 1491 to enable the serversystem 1400 to handle far more data than can be stored just in thedirect attached storage device 1475. Specifically, the cloud storagelayer's ability to store data at the cloud data storage provider 1491allows the hierarchical storage system 1404 to provide ever-expandingdata store on the server system 1400.

Integrated Hierarchical Data Storage Server Features

Having a server system with an integrated hierarchical storage systemgreatly simplifies the creation and support of satellite small offices.To illustrate the ease in which satellite offices can be supported, aset of examples will be presented with reference to FIGS. 15A to 15H.

FIG. 15A illustrate a block diagram of a company with a headquarters1510 and two satellite offices in London and Zurich. An administrator1511 at headquarters 1510 maintains two server systems 1560 and 1550 atthe satellite offices in London and Zurich, respectively that have anintegrated hierarchical data storage system. Each of the satelliteoffice server system (1560 and 1550) uses a regional cloud storageprovider to provide high-speed cloud storage service (1569 and 1559,respectively). Note that many countries have data privacy rules thatdescribe how data must be handled such that storing data with regionalcloud storage provider will help fulfill such legal obligations.

The company decides to open a new satellite office in Tokyo. To set up asatellite office in Tokyo, a new server system 1570 with an integratedhierarchical storage system is built and sent to the Tokyo office. Oncethe server system 1570 arrives at the new Tokyo office it is coupled toan internet connection and booted up.

After booting up the server system 1570, the administrator 1511 can loginto the server system 1570 and configure the server system 1570 foroperation as illustrated in FIG. 15B. One of the first tasks theadministrator 1511 does is to open an account with a local cloud storageprovider 1579 and configure the server system 1570 to use local cloudstorage provider 1579 as bottom tier of the hierarchical data storagesystem. At this point the Tokyo server system 1570 is ready to handle anever-expanding amount of data storage.

Next, the administrator 1511 may wish to create some virtual datavolumes and populate the Tokyo server system 1570 with applications anddata for use by the Tokyo office. To do this, the administrator 1511 mayconfigure the cloud storage layer in the Tokyo server system 1570 to usea server system 1507 at the headquarters 1510 as a source of data asillustrated in FIG. 15C. Then, the administrator 1511 may ‘restore’ asatellite office template volume 1551 at the headquarters 1510 withinthe Tokyo server system 1570.

FIG. 15D illustrates the state of the Tokyo server system 1570 afterrestoring the satellite office template volume onto the Tokyo serversystem 1570 and creating other needed data volumes. Note that thesatellite office template volume 1551 at the headquarters 1510 is onlybe used as back-up source volume. And that any changes made to therestored volume will only affect the local drive in the Tokyo serversystem 1570 and the cloud storage service 1579 used by the Tokyo serversystem 1570. Using conventional remote administration systems, theadministrator 1511 may install and configure any server applicationsthat are needed on the Tokyo server system 1570.

At this point, the Tokyo server system 1570 has been configure andloaded with applications ready for use. Thus, users at workstations 1571and 1572 may begin using the Tokyo server system 1570 as illustrated inFIG. 15E. Note that the entire configuration process was able to beperformed remotely by an administrator 1511 at the company headquarters1510.

After a year, the Company may decide that Tokyo is not the mostappropriate location for their far-east satellite office and may wish tomove the office to Singapore. The server system 1570 with a hierarchicalstorage system can greatly facilitate this task of moving the officecomputer infrastructure. The first task is to have the administrator1511 create a back-up of the needed data volumes from the Tokyo serversystem 1570. This may be performed by taking a snapshot of the neededvolumes and then creating cloud-based back-ups of the snapshot volumeseither at cloud store 1579 or at the company headquarters 1510. FIG. 15Fillustrates a back-up 1552 of the server system 1570 from the closedTokyo office at the server system 1507 in the company headquarters 1510.

Note that during the back-up process, all of the needed data from theregional cloud-storage system 1579 will be extracted and copied to theback-up 1552. Once all of the back-ups are complete, the Tokyo officemay be closed down and the contract with the regional cloud-storagesystem 1579 may be terminated as illustrated in FIG. 15G. Note that thetiming of such cloud provider change can be determined independently ofthe site transition and may happen at a later stage after the transitionhas completed. This allows for seamless transition on a permanent basisor in case of a temporary transition (e.g. in disaster recoveryfail-over situation) allows restoration of original services at theTokyo site as part of fail back.

A new Singapore office may then be quickly open by following the samesteps set forth with reference to FIG. 15A to 15E except that instead ofrestoring the satellite office template volume 1551, the administratorinstead restores the Tokyo office back-up volume 1552 at the newSingapore office. The final outcome is illustrated in FIG. 15H. Notethat if an unconfigured server system 1580 is set up and ready to go inthe new Singapore office before the Tokyo office is closed down then theTokyo server system 1570 can be backed-up immediately after the Tokyooffice closes for the last day and immediately restored at the Singaporeoffice. In this manner, the new Singapore office can open up the dayafter the Tokyo office closed with all of the data from the just-closedTokyo office immediately available at the new Singapore office!

The hierarchical storage systems can be used to easily distributevolumes of information to all of the different satellite office.Referring to FIG. 15I, the company headquarters 1510 has created alibrary volume 1553 as a back-up volume on server system 1507. Thelibrary volume 1553 contains information that the company headquarterswould like distributed to all of the different satellite offices such asthe company policy, information on the healthcare insurance, trainingvideos, software licensed for use by all employees, etc. To distributethe library volume 1553 to all of the satellite offices, theadministrator contacts each of the server systems 1550, 1560, and 1580and instructs those servers to restore the library volume 1553 as alocal volume. Each satellite server 1550, 1560, and 1580 will thencreate a local volume that contains all the information from the libraryvolume 1553.

Note that all of the data from the library volume 1553 may not beimmediately transmitted to all of the satellite servers (1550, 1560, and1580). Instead, just an index of information needed to create theappearance of a local library volume 1553 is transmitted initially.Then, as users at the various satellite offices request documents fromthe local instance of the library volume, various pieces of the libraryvolume 1553 will be transmitted as requested. This technique reducesunnecessary network bandwidth usage and does not waste local storagespace for documents that no user will access.

Integrated Hierarchical Data Storage in the Cloud

There are times when even managing a single small physical server 1350as illustrated in FIG. 13 may not be ideal. For example, if there are anumber of individual salespeople working in distant geographical regionsthen there is no convenient central office to host a server for thoseremote salespeople. Alternatively, a company may decide to outsource thephysical maintenance of all server hardware by just moving allserver-based applications to a cloud-based computer service provider. Toaccomplish this goal, the server system 1400 with an integratedhierarchical storage system 1404 may be moved into a cloud-based virtualserver. Ideally, the cloud-based computer service provider will belocated at a geographical location relatively close to the users suchthat response times are optimized.

FIG. 16 illustrates a virtual server system 1600 with an integratedhierarchical storage system 1604 that is executing at a cloud serviceprovider 1699. By moving the server system to a cloud-based serviceprovider, an entity can eliminate and outsource all the tasks ofphysically maintaining server hardware. Individual users, such as a userat thin-client system 1698, may access server applications from thevirtual server system 1600 across the interne 1690. Thus, manygeographically remote individual users (such as geographically dispersedsales personnel) can all share server applications 1656 and 1656.

Note that within a cloud-based environment, the advantages of thedifferent layers of the hierarchical storage system 1404 may not beappreciated as much. For example, when executing in a cloud-basedenvironment, the linear storage layer 1640 may not have a very lowlatency response since the cloud-based environment may not supportallocating certain regions of storage as solid state memory but willinstead use disk storage as illustrated in FIG. 16. Thus, the storagesize allocations and eviction policies used for the various storagelayers may be adjusted to adapt to the cloud environment.

The virtual server system 1600 implementation of FIG. 16 uses thespecialized virtual storage driver 1680 to provide storage services toapplication programs. Due to this architecture, any server applicationsthat wish to use the hierarchical storage system 1604 must run on thesame virtual server system 1600. For example, server applications A 1656and B 1657 execute on the virtual server system 1600 and thus can accessthe virtual storage driver 1680 in that virtual server system 1600. Toimprove performance, each application program may be assigned its ownindividual virtual machine.

FIG. 17 illustrates a cloud service provider 1799 that is running twoseparate virtual server systems (1700 and 1701) wherein each serversystem is running a single server application (1756 and 1757,respectively). Additional virtual servers may be spawned to handleadditional applications wherein each virtual server has its ownhierarchical storage system instance. This arrangement allows the systemto take advantage of the cloud computing aspect of being about to scaleout instead of scale up. Specifically, multiple different computerinstances may be assigned handle individual tasks instead of using asingle large computer instance that runs multiple disparateapplications. Thus, for similar tasks, a system may use a cluster ofsmaller nodes that can grow or shrink in members, rather than one largecompute node that consumes a predefined set of resources.

In an alternate embodiment, the hierarchical storage system may begeneralized to allow other applications running on other machines (realor virtual) to more easily access the cloud-based hierarchical storagesystem. FIG. 18 illustrates a virtual hierarchical storage system 1804that is executing at a cloud service provider 1899. However, the virtualhierarchical storage system 1804 exposes a network storage interface1880 such as an iSCSI interface to the outside world. In this manner,server applications A 1871, B 1872, and C 1873 can run in their ownvirtual systems (or on physical system at an office) and access thestorage services through the network storage interface 1880. Anindividual user at thin-client system 1898 is illustrated accessing theserver application C 1873 across the internet 1890.

Note that the embodiment of FIG. 18 makes it easier to scale upapplications services faster. Specifically, as many instances ofapplications are necessary may be created in their own virtual serversand allowed to access the same network storage interface 1880 such thatwhen processing power is needed to handle numerous simultaneous users,application processing power can be scaled up quickly.

Disaster Recovery Using Data Storage in the Cloud

The ability to host a virtual hierarchical storage system 1804 withincloud-based service provider 1899 offers the ability to create alow-cost disaster recovery system for any entity that uses ahierarchical storage system. With either the hierarchical storageappliance 460 of FIG. 4 or integrated hierarchical storage server 1350of FIG. 13, an administrator can easily create daily back-up volumesstored at the cloud storage provider used by the hierarchical storagesystem. Thus, if a disaster strikes (such as an office building housingthe hierarchical storage appliance 460 or integrated hierarchicalstorage server 1350 burns down), the most recent back-up volume can berestored into cloud-based virtual hierarchical storage system 1804 atcloud service provider 1899. Once the back-up data volumes are restoredat a virtual hierarchical storage system 1804, cloud-based applicationprograms such as applications 1871, 1872, and 1873 may begin operatingusing the restored data volumes.

Thus, simply by creating regular cloud-based back-up volumes, anyorganization that uses a hierarchical storage system has the ability toquickly restore an entire back-office infrastructure within a cloudservice provider 1899. The stand-by disaster recovery effectively costsnothing to maintain since an account with a cloud service provider 1899can immediately be open when a disaster strikes.

The preceding technical disclosure is intended to be illustrative, andnot restrictive. For example, the above-described embodiments (or one ormore aspects thereof) may be used in combination with each other. Otherembodiments will be apparent to those of skill in the art upon reviewingthe above description. The scope of the claims should, therefore, bedetermined with reference to the appended claims, along with the fullscope of equivalents to which such claims are entitled. In the appendedclaims, the terms “including” and “in which” are used as theplain-English equivalents of the respective terms “comprising” and“wherein.” Also, in the following claims, the terms “including” and“comprising” are open-ended, that is, a system, device, article, orprocess that includes elements in addition to those listed after such aterm in a claim is still deemed to fall within the scope of that claim.Moreover, in the following claims, the terms “first,” “second,” and“third,” etc. are used merely as labels, and are not intended to imposenumerical requirements on their objects.

The Abstract is provided to comply with 37 C.F.R. § 1.72(b), whichrequires that it allow the reader to quickly ascertain the nature of thetechnical disclosure. The abstract is submitted with the understandingthat it will not be used to interpret or limit the scope or meaning ofthe claims. Also, in the above Detailed Description, various featuresmay be grouped together to streamline the disclosure. This should not beinterpreted as intending that an unclaimed disclosed feature isessential to any claim. Rather, inventive subject matter may lie in lessthan all features of a particular disclosed embodiment. Thus, thefollowing claims are hereby incorporated into the Detailed Description,with each claim standing on its own as a separate embodiment.

1. A method comprising: in a server system connected to a networkconnection and comprising a hierarchical storage stack for storing data,wherein the hierarchical storage stack comprises a local data storagelayer for storing data locally in the server system and a remote datastorage layer that stores data with a remote data storage service;utilizing the local data storage layer as a read-ahead cache for theremote data storage layer by: identifying a selected data object of theremote data storage layer that is absent in the local data storagelayer; and before receiving an incoming request to access the selecteddata object, moving the selected data object from the remote datastorage layer to the local data storage layer.
 2. The method of claim 1,wherein the selected data object is identified using heuristics toidentify data that is likely to be requested soon.
 3. The method ofclaim 1, wherein the selected data object is accessed infrequently but alow latency response is needed when the data object is accessed.
 4. Themethod of claim 1, wherein the remote data storage service comprises anoff-site data storage provider.
 5. The method of claim 1, furthercomprising exposing a network storage interface for applications toaccess the hierarchical storage stack.
 6. The method of claim 1, whereinthe hierarchical storage stack further comprises an administrative layerthat allows remote configuration and control of the hierarchical storagestack and further comprising: remotely accessing the administrationlayer in the server system through the network connection to configurethe server system.
 7. The method of claim 6, further comprising:receiving in the administration layer a request to create a new datavolume in the server system; allocating the new data volume in thehierarchical storage stack; and creating storage space for the new datavolume by transferring data from the local data storage layer to theremote data storage layer.
 8. The method of claim 6, further comprising:receiving in the administration layer a request to restore a datavolume; copying a data volume snapshot index into the hierarchicalstorage stack to create a restored data volume, the data volume snapshotindex referencing data in a remote server; and copying data from theremote server as data in the restored data volume is requested by localusers of the server system.
 9. The method of claim 6, further comprisingperiodically polling, by the administration layer, the local datastorage layer and the remote data storage layer to generate statisticsrepresenting performance of the hierarchical storage stack.
 10. A systemcomprising: a processor; a network interface; a hierarchical storagestack for storing data comprising at least a local data storage layerfor storing data locally in the system and a remote data storage layerthat stores data with a remote data storage service; and memory storinga set of computer-executable instructions that, when executed by theprocessor, cause the system to perform the operations of: utilizing thelocal data storage layer as a read-ahead cache for the remote datastorage layer by: identifying a selected data object of the remote datastorage layer that is absent in the local data storage layer; and beforereceiving an incoming request to access the selected data object, movingthe selected data object from the remote data storage layer to the localdata storage layer.
 11. The system of claim 10, wherein the selecteddata object is identified using heuristics to identify data that islikely to be requested soon.
 12. The system of claim 10, wherein theselected data object is accessed infrequently but a low latency responseis needed when the data object is accessed.
 13. The system of claim 10,wherein the remote data storage service comprises a cloud-based virtualserver.
 14. The system of claim 10, wherein the local data storage layercomprises a first local data storage layer that stores data in a rawformat and a second local data storage layer that stores data in aformat with duplicate data removed.
 15. The system of claim 10, furthercomprising a data volume in the hierarchical storage stack that willinitially store data in the local data storage layer and later spilldata to the remote data storage layer.
 16. The system of claim 10,wherein the hierarchical storage stack further comprises anadministrative layer that allows remote configuration and control of thehierarchical storage stack and the operations further comprise: remotelyaccessing the administration layer in the system through the networkconnection to configure the system.
 17. A non-transitorycomputer-readable medium storing a set of computer-executableinstructions that, when executed by a processor, cause a computingdevice to perform the operations of: installing a system comprising ahierarchical storage stack for storing data, the hierarchical storagestack comprising a local data storage layer for storing data locally inthe system and a remote data storage layer that stores data with aremote data storage service; and utilizing the local data storage layeras a read-ahead cache for the remote data storage layer by: identifyinga selected data object of the remote data storage layer that is absentin the local data storage layer; and before receiving an incomingrequest to access the selected data object, moving the selected dataobject from the remote data storage layer to the local data storagelayer.
 18. The non-transitory computer-readable medium of claim 17,wherein the selected data object is identified using heuristics toidentify data that is likely to be requested soon.
 19. Thenon-transitory computer-readable medium of claim 17, wherein theselected data object is accessed infrequently but a low latency responseis needed when the data object is accessed.
 20. The non-transitorycomputer-readable medium of claim 17, wherein the system furthercomprises an administrative layer that allows remote configuration andcontrol of the hierarchical storage stack and the operations furthercomprise: remotely accessing the administration layer in the systemthrough a network connection to configure the system.